IT 19 050 


Examensarbete 15 hp 
September 2019 





UNIVERSITET 


Monads in Haskell and Category 
Theory 


Samuel Grahn 


Institutionen for informationsteknologi 
Department of Information Technology 





UPPSALA 
UNIVERSITET 


Teknisk- naturvetenskaplig fakultet 
UTH-enheten 


Besdksadress: 
Angstrémlaboratoriet 
Lagerhyddsvagen 1 
Hus 4, Plan 0 


Postadress: 
Box 536 
751 21 Uppsala 


Telefon: 
018 — 471 30 03 


Telefax: 
018 — 471 30 00 


Hemsida: 
http://www.teknat.uu.se/student 


Abstract 


Monads in Haskell and Category Theory 


Samuel Grahn 


The monad is a mathematical concept, used by Haskell to describe 

— among other things — Input/Output. Many are intimidated by it 

since it stems from abstract mathematics — namely Category Theory. 
However, the mathematics required to use and understand the monad is 
straight forward and intuitive, and can be explained through incremental 
definitions and proofs. This paper intends to construct and explain the 
monad from the ground up and show some example uses for it. 
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1 Introduction 


1.1 Motivation 


Through the development of computer science, mathematics has been a very 
important tool. From the basic logical circuits the transistor enabled to the 
computability, complexity and formalization of the Turing Machine. Abstrac- 
tions — through mathematics — have moved the knowledge requirements for 
writing software from the hardware level with electronics and circuits, to ma- 
chine language, to assembly, and on towards higher level languages. 

One useful class of abstractions are those of the functional languages; lan- 
guages in which functions are treated as first-class objects. As a way to elimi- 
nate unpredictable behaviour, functional languages generally disallow mutation, 
changing the value of a variable. This has the effect that a function will always 
return the same value, when passed the same arguments, preventing small issues 
from creating a butterfly effect at unrelated parts of the program. 

There is one problem that needs to be solved however, and that is the issue 
of Input/Output. 

If no function is allowed to alter the global state — as this would cause the 
next function call to have different effects, how is a program supposed to output 
data to the console? How to read a file, whose contents might change between 
reads? 

One answer to this, the answer chosen by Haskell[4], is to abstract the 
changes away; to wrap them in a separate object, an object that keeps track of 
the outside world. This object is called the JO monad|4, Chapter 41], and while 
the category theoretic concept of a monad[1, p.137] has many other uses than 
IO[4, p.156], it is a good motivation for exploring it. This thesis aims to provide 
the reader with an understanding of the monad and its prerequisite category 
theoretic concepts, both of the mathematical objects and of the practical uses 
in functional programming. 


1.2 Method 


In order to explain the monad, we need some previous knowledge. The monad 
is a monoid in the category of endofunctors. While this sounds vague and com- 
plicated, it is just a description of how and what it consists of. After explaining 
each of these concepts in turn, the monad will be a simple extension. 

We will begin by stating any prerequisite knowledge, closely followed by 
a incremental construction of category theory, along with code that shows its 
practical uses. 

The first thing we need to know, is our programming language of choice; 
Haskell. 


2 Haskell 


Haskell is a pure, functional language which makes heavy use of monads and 
other abstractions from category theory. It has a lot of features, but we will 
only be using a select few in order to keep the code examples as close to our 
mathematical notation as possible. 


-- Comments begin with two dashes 
== Declare the type of a variable 
ao:: Int 


-- And its value 
a=tl 


== 0F a function 


double :: Int -> Int 
-- And its definition 
double x = x * 2 


-- Functions can be passed as arguments 

apply :: (Int -> Int) -> Int -> Int 

-- apply takes a function f, and an int x, and applies f to x. 
apply f x =f x 

-- or equivalently using lambda notation 

apply = \f x -> f x 


-- When the program is run, it prints the number 2 
main = print (apply double a) 


We will be using some syntactic sugar to help make code more readable. 


1. ($) :: (a -> b) -> a -> b, can be used instead of parentheses to spec- 
ify argument locations. For example, the expression f $ x + y evaluates 
to the same result asf (x + y). 


2. \x -> x + 2,an anonymous function. The function itself is equivalent to 
a function f defined as f x = x + 2, but it is nameless and is sometimes 
easier to express. 


3. [a], shorthand for the type of list with elements of type a, equivalent to 
[] a 


We will be using two more features of Haskell, namely custom types and classes. 
A type is declared by stating its name and its possible values, each of which 
may have parameters. 
A class, not to be confused with classes from object oriented programming, 
is a promise that a type supports a set of functions; in order to implement 
a class for a type, it is required to provide implementations for each of the 


functions the class promises to deliver. Some of these functions can have default 
implementations. These implementations may use any of the constraints placed 
upon the class itself, as well as the other functions within the class, but no other 
assumptions can be made about the types. 


-- Simple datatypes without parameters 
data Language = Swedish | English 
data Animal = Cat | Cow 


-- Both of the above datatypes can be viewed as social in some way, 
-- so we define a common behaviour 
class Social a where 

greet :: a -> String 


-- And implement this behaviour 
instance Social Language where 
greet Swedish = "Hej" 
greet English = "Hello" 


instance Social Animal where 
greet Cat = "Meow" 
greet Cow = "Moo" 


-- A function can take general types as parameters (a -> b), 
-- and can impose restrictions on these types (Social a). 
interaction :: (Social a, Social b) => a -> b -> String 
interaction a b = 

(greet a) ++ (greet b) 


-- This simply prints "MooHello" into the console 
main = print (interaction Cow English) 


These classes are used to model mathematical objects. The most simple of 
which - the monoid, is our first building block. 


3 Monoid 


Mathematically speaking, a monoid is a simple construction, consisting only of 
a set of objects C, and a way to combine two objects of C' into an object of C; 
the operator -: C x C' > C, subject to two rules [8, p.3]; 


1. Associativity: a-(b-c) = (a-b)-c 


2. Identity: There exists a lc € C' such that lo- x = a = 2- le, for all 
rEeC. 


These rules are of course still present in Haskell, albeit not enforced or 
checked by the compiler. All built-in instances of monoids satisfy these condi- 


tions, and any user-implemented instances are encouraged to satisfy them as 
well, simply for mathematical consistency. 

In Haskell, the operation (-) on a monoid is mappend (monoid-append), which 
is named after the list monoid. The identity element, 1c, the element with 
which every other element simply composes into itself is also named after the 
list monoid, mempty (monoid-empty). More abstract examples include functions 
a -> a, with function composition as operation and the identity function id as 
identity. 

The typeclass Monoid is a subclass of Semigroup, meaning each monoid is 
also a semigroup. This means that to instantiate a monoid, you first need to 
instantiate a semigroup. The difference between the two is that in a semigroup 
there is no requirement of identity, and the combination operator is the operator 
<>. Note that mappend has a default implementation mappend = <>. Trivial 
examples can be implemented as follows 


-- The nonnegative integers 

-- represented as a list data structure 

-- | Zero is 0, Seq (a) is the number after a. 
-- | Seq (Seq Zero) = 2 

data PosInt = Zero | Seq (PosInt) 


instance Semigroup PosInt where 
Zero <> x = xX 
y <> Zero = y 
(Seq x) <> Seq y = Seq (Seq (x <> y)) 


-- The nonnegative integers form a monoid with addition 
instance Monoid PosInt where 
mempty = Zero 


-- The booleans with the or-operator form a monoid 
instance Semigroup Bool where 
False <> False = False 
_ <> _ = True 
instance Monoid Bool where 
mempty = False 


The monoid is a useful construction, and its structure often reappears in 
mathematical objects. It is, however, an important structure that will reappear 
as we delve into Category Theory. 
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4 Categories 


Categories are the basic construct of category theory. The mathematical object 
upon which all others are based. 
Formally, a category C consists of [3, p.582] 


1. a collection of objects. We use a collection instead of the more tradi- 
tional set, in order to effectively allow the Category of Categories. For the 
purpose of this thesis, however, it is sufficient to consider them roughly 
equivalent to sets. 


2. a collection of morphisms, also known as arrows, between objects. Each 
morphism has a source and a target object, which for a morphism f we 
write as f : a > b. Further, by hom(a,b) we mean the collection of all 
morphisms from a to b. 


3. a binary operation o : hom(a,b) x hom(b,c) > hom(a,c), for all objects 
a,b,c, called composition. Further, this operation requires that the fol- 
lowing axioms hold 


(a) Associativity; if f:a—>b,g:b3¢h:cod 
then ho(go f)=(hog)of. 

(b) Identity: For every object x there exists a morphism 1, : « > x such 
that composition with another morphism simply yields that other 
morphism. 


4.1 Commutative Diagrams 


The equations and laws of category theory often get complex and difficult to 
understand when using only the standard mathematical notation. Therefore, 
category theorists developed a different way to represent categories and their 
relations — using commutative diagrams. In fact, through rigorous definition of 
diagrams, one could define categories using diagrams only. 

For instance, a category C with objects A,B and morphisms f : A > B, 
g: B- Acan be drawn as 


The identity morphisms are typically not drawn, since they always exist, 
and would mainly contribute clutter to the diagram. Relations on categories 
can also be represented as diagrams. 


4.2 Monoid as a Category 


Given any monoid M we can consider the following functions. 


fa: M>M, fa(x) =a-2 
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These functions can be considered morphisms of a single object category Cay. 
We can inspect the axioms for a category, and state that fi(z) = ly - wx is the 
identity morphism for the single object of Cjz, and since the monoid operation 
is accosiative we have f,o(f,° fe) = a-(b-c) = (a-b)-c=(fao fh) fe, 80 Cry 
is indeed a category, as represented by the following diagram. 


(CM _) fh 
Conversely, given any category C with only one object x, we can construct a 
monoid M by letting each morphism f : « > x map to an object f in M, and 
composition of morphisms be represented as fog = f-g. Thus, any monoid is 


a Category, and any category with a single object is a monoid (with morphisms 
representing the elements of the monoid). 


4.3. The Category Hask 


Now that we know what a category is, we can start connecting the dots to 
Haskell. The most interesting category in our case is the category Hask, the 
base of Haskell’s type system. 


In Hask, the objects are the types of Haskell (Int, Double, et.c.), and the 
morphisms are Haskell functions f : A + B, where A and B are Haskell types. 
The composition of two morphisms is the operator (.) in Haskell, defined as[4, 
Chapter 9] 


(.) :: (B -> C) -> (A -> B) -> (A -> C) 

f .g=\x -> f (g x) 

In Hask, two functions, f,g are considered to be the same morphism if for all 
x, f(x) = g(x), despite them being different functions in Haskell. The identity 
morphism in Hask is the function|4, Chapter 9] 

id :: A-> A 

id x =x 


4.4 Subcategories 


If you have a category and disregard some of its objects, and all morphisms 
either to or from these objects, you have a subcategory. For instance, the right 
category is a subcategory of the left category in the following diagrams. 


A—>B A—+>B 
C ——+ D C 
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In Hask, the subcategories are commonly viewed as the types wrapped into 
data types. For instance, [a], the type of the linked list, is a subcategory of 
Hask. The elements within that list follow the same structure as if they were 
not in a list, while the list itself provides an additional structure. 

In order to actually use the concept of categories in Haskell, we introduce 
the simplest operation upon them: the functor. 


5 Functors 


Functors are the next building block of category theory. It is a mapping between 
two categories; a way to turn one category into another. 

When talking about functors in Haskell, however, one usually refers to some 
kind of container. This is a good way to get a basic understanding for some of 
its use cases. 


class Functor f where 
fmap :: (a -> b) -> f a -> f b 


-- The functor instance for list 
instance Functor [a] where 

fmap f [] = [] 

fmap f (x : xs) = (f x) : (fmap xs) 


-- Or equivalently 
instance Functor [a] where 
fmap = map 


data Maybe a = Just a | Nothing 
-- The functor instance for Maybe 
instance Functor Maybe a where 
fmap f Nothing = Nothing 
fmap f (Just x) = Just (f x) 


If we look closer at these definitions, we can see the notion of containers 
quite clearly. The type Maybe a, for instance, which may or may not contain 
a value of type a. Regarding functors as containers in Haskell allows you to 
use most of them without any further knowledge of category theory. However, 
the functor is more abstract than just containerization, and can apply to many 
other use cases. Those, however, require more mathematics. 


5.1 Functors in Category Theory 


Formally [8, p.586], a functor F' : C > D is a mapping from the category C, to 
the category D. It associates each object X € C to an object F(X) € D, and 
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each morphism ¢: X + Y in C toa morphism F(¢) : F(X) > F(Y) in D. 


a 104 


6 F(9) 


Y —> F(Y) 


Subject to two conditions: 
1. F(1x) = 1px) for every X in C. 
2. Figo f) = F(g)° F(f) for all morphisms f: X > Y,g:Y > Z. 








ft ye 
pore 
F(X) Soe FY) a> F(Z) 


So a functor preserves identity morphisms and composition of morphisms. 


5.2 Functors in Haskell 


When referring to functors in Haskell, what is usually meant is actually only a 
subset of possible functors, the functors from a category unto itself, the end- 
ofunctors. In Hask, the endofunctors are represented as a typeclass with a 
single function, fmap, which takes a function a -> b, and lifts it into a function 
f a -> f b, that performs that same computation on the wrapped objects. We 
frequently use the infix operator <$>, which is a synonym to fmap, defined as 
f <$> x = fmap f x. 


5.2.1 Functor Laws in Haskell 


Implementing each function in the Functor typeclass is not enough to be a 
proper mathematical functor. Satisfying the laws of the functor object is the 
task of the programmer when implementing fmap. The first law — preserving 
of identity — is equivalent to the statement 

fmap id = id 


The second law, preserving of composition, is equivalent to the statement 


fmap (g . h) = (fmap g) . (fmap h) 
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5.3 List is a Functor 


The built-in functors of Haskell satisfy these laws. As an example, we can view 
the functor instance for lists, and note that 


fmap id (x:xs) 
= (id x) : fmap xs 


=x : fmap xs 


Which inductively gives us fmap id (x:xs) = (x:xs), satisfying the first law. 
We can also see that 


(fmap g) . (fmap h) (x : xs) 
=fmap g (fmap h (x : xs)) 
=fmap g ((h x) : fmap h xs) 
=(g.hx) : fmap g (fmap h xs) 


which inductively gives us the second law, meaning the list functor is indeed a 
functor. All instances of Functor in Haskells’ standard library satisfy these laws 
[4]. 


6 Applicative Functors 


Haskell consists of several data types that have more in common than just being 
functors, but that don’t quite match all requirements for being a monad. For 
this reason, Haskell has another subclass between the functor and the monad: 
the applicative functor. An applicative functor is the last stepping stone in our 
construction of the monad. Its type class has three functions 


class Functor f£ => Applicative f where 


pure :: a->fa 
(<*>) :: f£ (a -> b) -> f a -> f b 
liftA2 :: (a -> b -> c) -> fa ->f b-—-> fe 


(<*>) = liftA2 id 
liftA2 g x y = g <$> x <*> y 


where the default implementations of (<*>) and 1iftA2 means only one of them 
needs manual implementation, along with the implementation of pure. 

From the types we can see that pure takes an arbitrary value, and turns it 
into an applicative — and into a functor, since each applicative is also a functor 
— containing this value. The other functions, (<*>) and 1iftA2, are about 


sequencing. 
To make the uses more clear, assume you have a function foo :: a -> b -> ¢, 
and variables x :: f aandy :: f b, where f is an applicative functor. You 
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can supply foo with the contents of x,y through the following two equivalent 
expressions. 


pure foo <*> x <*> y 
1iftA2 f x y 


The most trivial example is that of the Maybe Applicative, where we from 


instance Applicative Maybe where 


pure = Just 
(Just f) <*> (Just x) = Just (f x) 
<*> _ = Nothing 


foo x y=xty 
a = Just 1 
b = Just 2 


c pure foo <*> a <*> b 


get the result c = Just 3. Another example is the list applicative [4, Chap- 
ter 9]. 


instance Applicative [a] where 
pure x = [x] 
fs <*> xs = [f x | f£ <- fs, x <- xs] 


This implementation, is using list comprehension to make it easier to read. 
For every f in fs, and every x in xs, the list consists of the values of f x. 
This means that for every value in the list xs, each function in the list fs is 
applied. For instance [(+1), (+2)] <*> [5,10] = [6,11, 7, 12]. While 
the applicative typeclass have no significant purpose in category theory, it is 
useful as an abstraction in Haskell. Using this final subclass of the monad, we 
can finally approach the monad in Haskell. 


7 Monads in Haskell 


The monad instance is defined as follows [4, Chapter 9] 


class Applicative m => Monad m where 
(>>=) :: ma-> (a -> mb) -> mb 
(>>) :: ma->m b->m b 


m>> k=m >>= \. -> k 


Feturn ftoasmama 
return = pure 


The primary use case of the monad is to emulate sequential actions, much in 
the same way that semicolons operate in C-like languages. This chaining of 
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operations, wrapped in a separate functor container, gives us the tools to deal 
with many of the issues functional programming provides. 


7.1 Do-notation 


In order to simplify the syntax for sequencing monadic operations, Haskell pro- 
vides what is called do-notation. This is a compiler feature, replacing matching 
syntax with the monadic operations. Using this syntax, the following function 
definitions of doPutStr and putStr are equivalent, as are the definitions of 
doBindop and bindOp. 


doPutStr = do { 
putstr "Hello " 
putstr "World" 
} 


putstr = putStr "Hello " >> putStr "World" 


doBindOp = do 
si <- getLine 
s2 <- getLine 
putStr (si ++ s2) 


bindOp = getStrLn >>= (\si -> getStrLn >>= (\s2 -> putStr (sl ++ s2))) 


7.2 Maybe 


Using the Maybe monad we can deal with error handling, and other types of 
functions that not always have a value to return [4, Chapter 9]. 


instance Monad Maybe where 
return = pure 
(Just x) >>= f =fx 
Nothing >>= f = Nothing 


Some examples of its usefulness are 


-- Prevents runtime errors when dividing by zero 


(/.) :: Integral a => a -> a -> Maybe a 
x /. y = if y == 0 then Nothing else Just $ x “div” y 
-- Examples 


a= (3 +2) /. 1 
-- a = Just 5 


b= (84 2) /. 0 
=- b = Nothing 
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-- Get element at nth position of a list. 
== If it's net there, return Nothing 


at :: [a] -> Int -> Maybe a 
at (x : xs) 0 = Just x 

at [] _ = Nothing 

at (_ : xs) n = at xs (n-1) 
7.3 State 


One of the useful applications for monads is the State monad. It emulates the 
notion of a state by having a hidden variable wrapped in a monad. When this 
monad is used to call functions, this state can change, and the results of the 
functions can depend upon it. 


In the Haskell library, the State monad is defined as 


newtype StateT s ma = StateT { runState :: s -> m (a,s) } 


newtype State s = StateT s Identity 


For our purposes, however, we will ignore the abstraction of StateT, and 
define[2| 


newtype State s = State { runState :: s -> (a,s) } 
We can then instantiate the state monad from the ground up as 


instance Functor (State s) where 
fmap f s = State $ \w -> 
let (ma, ns) = runState s w 
in (f na, ns) 


instance Applicative (State s) where 
pure x = State $ \s -> (x,s) 
sf <*> sv = State $ \w -> 


let 
(v, si) = runState sv w 
(f, s2) = runState sf si 


im (f v, $2) 


instance Monad (State s) where 
return = pure 


p >>= k = State $ \sO -> 


let (x, si) = runState p s0 
in runState (k x) st 
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The state monad is accompanied by some helper functions that enable for chang- 
ing the state itself, namely using put and get. 


get :: State ss 
get = State $ \s -> (s,s) 


put :: s -> State s () 
put x = State $ \s -> ((), x) 


evalState :: State sa ->s >a 
evalState a = fst . runState a 
execState :: State sa->s -> s 
execState a = snd . runState a 


get leaves the state unchanged and sets its value to the state itself, and 
put replaces the state value, leaving the value as the unit. evalState and 
execState are used to evaluate a sequence of state operations and return the 
value or the state itself, respectively. 


7.3.1 State-based Game 
An example use is the following trivial game. 


playGame :: String -> State (Int, Int) Int 
-- Plays a game using a string 
-- + adds i to value 
== = subtracts 1 from value 
-- x stores value into memory 
-- * multiplies value by the value in memory 


-- The goal is to provide a string computing 
-- a certain value according to some constraint. 
-- (Example: shortest string computing the number 42) 


playGame [] = do 
(_, score) <- get 
return score 


playGame (x:xs) = do 
(mem, score) <- get 
case x of 


'+' -> put (mem, score +1) 
'-' -> put (mem, score -1) 
'*' -> put (mem, score * mem) 
'x' -> put (score, score) 


playGame xs 
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The state monad is used as a container for the current game state; the value 
in memory and the current score. At each step, the game checks the next 
character, changes its state accordingly, and proceeds to the next character. 


7.3.2 Tree Relabeling 


Another example is that of relabeling the nodes of a (in this example, binary) 
tree. 


import Control.Monad.Trans.State 
data Tree a = Empty | Node a (Tree a) (Tree a) deriving Show 


relabel::Tree a -> Tree Int 
relabel t = evalState (relabeli t) 0 


relabell:: Tree a -> State Int (Tree Int) 
relabell Empty = do return Empty 
relabel1 (Node _1r) = 
do 11 <- relabeli 1 
label <- get 
put (label + 1) 
ri <- relabell r 
return (Node label 11 ri) 


The function relabel1 takes a tree, and traverses it, starting by descending 
the left branch, followed by the current node and finally the right branch at 
each node, giving each node the value of the current number of nodes already 
traversed. Given a binary search tree, for instance, the function assigns to each 
node the position of itself in an ordered list, i.e. how many nodes are smaller 
than it. 


True 1 

y 7 
—relabel —> 0 3 

i ™ a 

False True 2 4 


Note that the values of the nodes in the source tree does not matter, only the 
structure of the tree does. 

If we look at the function relabel1, we can see that it traverses the tree 
depth first, left to right. 


7.3.3 Unfolding Tree Relabeling 


The functionality the relabling example provides can of course be implemented 
without monads as well. For instance, the following program is (computation- 
ally) equivalent 
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relabel' t = fst . relabeli' t 0O 


relabeli' :: Tree a -> Int -> (Tree a, Int) 
relabel1' Empty n = (Empty, n) 
relabel1' (Node _1r) n= 
let 
(11, ni) = relabeli' lo 
label = nil 
n2 = label + 1 
(ri, n3) = relabeli' r n2 
in 
(Node label 11 ri n3) 
We can show this by considering the base case and the recursive case inde- 
pently. For the base case, we have 


relabel' Empty = fst . relabeli' Empty 0 
= fst . (Empty, 0) 


Empty 


and 


relabel Empty = evalState (relabeli Empty) 0 
= fst . runState (relabell Empty) 0 
= fst . runState (return Empty) 0 
= fst . runState (State $ \s -> (Empty, s)) 0 
= fst ((\s -> (Empty, s)) 0) 
= fst (Empty, 0) 
= Empty 


The recursive case can be done similarly, but is left as an exercise to the 
reader. This conversion of monadic programs to regular programs can help 
convince us that the monad is not magic. 


8 Monads in Category Theory 
The basic understanding of monads as a tool in Haskell can be further evolved 


by exploring the category theory behind it. To do this, we need to understand 
the concept of natural transformations. 
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8.1 Natural Tranformations 


Given two functors, F,G between categories C,D, a natural transformation 
w: F > Gis a collection of morphisms in D [3, p.417]. The morphisms must 
satisfy the following conditions 


1. For every object x in C, there is a morphism y, : F(x) > G(x), called 
the component of w at zx. 


2. Components must satisfy that for every morhpism f : X — Y in C, we 


have py o F(f) = G(f) 0 we. 


po 
= 


G(f) 


That is, a natural transformation can be seen as a way to transform one functor 
into another. Further, if each , is bijective, it is said that w is a natural 
isomorphism, and that F and G are isomorphic. Note that while the notation 
hints at w being a function between F' and G, F and G are not sets, so the 
notation simply means that Ww transforms a functor F to another functor G. 


8.1.1 Example 


In order to make the concept of natural transformations more clear, we will 
construct a simple one. 
Let C be the category defined by the diagram 


es are 
c 
Let F be a functor F : C > C with F(a) = F(b) = F(c) = a and F(f) = 
F(g) = F(h) = la, and let I be the identity functor on C that maps each 


object to itself, and each morphism to itself. 
Let y: 1 > F bea natural transformation with components 








Ya =hogof=l, 
~o=hog 
Ye=h 
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We note that every x € C there is a morphism (yz, so the first law is satisfied. 
Next, we examine the morphisms, and show that 


yool(f)=hogof=(hogof)ola=F(f)° va 
Yeo l(g) =hog=1q0 (hog) = F(g)o yb 
pacl(h)=hofogoh=Fi(h)oy, 


So F is a natural transformation, transforming C into the subcategory 


la 


é 


a 


8.2 Composition of Natural Transformations 


Ifa:F > Gand 6: G > A are natural transformations between functors 
F,G,H :C > D, we can construct a natural transformation Goa: F > H, by 
componentwise defining (Goa), = 8,a,. Next, given a natural transformation 
€ : F + G between functors F,G : C — D, and functors H; : B —> C, 
H2:D — E, we can define natural transformations H,é : H,F — H,G and 
€H2 x FH: — GH» as 


(Af) = ANE, 
(€H2)2 = x(x) 


There is a third way to compose natural transformations which is irrelevant for 
our purposes, so we can ignore it. 

These compositions of natural transformations will become useful in the 
following definition. 


8.3 Monads 


A monad on a category C consists of an endofunctor T': C > C together with 
two natural transformations [1, p. 137]: 


e 7:1c—T, where 1c is the identity functor on C 
t(ePorset 
Subject to the following criterion [1] [2] 

1. poTp=popT 


T3 es 7) 


a. | 


T? —+T 
Lb 
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2. woTn = ~onT =17, where |r is the identity morphism from T to T. 


N 


8.4 Power Set Monad 


A simple example of a monad is the power set monad. 

Let Set be the category of all sets, with morphisms as functions between 
them. Let T : Set > Set be an endofunctor with T(A) = {X € Set|X C A} 
for objects A of Set, i.e. the power set of A, and for morphisms f : A > B, 
T(f) : T(A) > T(B), for each subset A; of A, let T(f)(A;) = {f(x) | x € Aj}, 
in other words, map each subset of T(A) to its image in T(B). 

First, we need to prove that T is indeed a functor. The identity morphism 
on each object A € Set is the function 14(”) = x. For each A; of T(A) we get 
T(1a)(A;) = {la(a) | x € A;} = {Aj}, ie. the identity morphism on A;, so the 
first functor law is satisfied. 

As for the second functor law, consider f : A— B, g: BC. We have for 
each A; € A, that 


(T(g) oT(f))(Ai) 


l 


T(g9)(T(f)(Ai)) 
T(g9)({fla) € T(B) | a € Ai}) 
{g(b) | b€ {f(a) € T(B) | ae Aid} 
{g(f(a)) | a € Aa} 
={(g0 f)(@) | ae Ait 
=T(go f)(Ai) 

so the second functor law also holds, meaning T’ is indeed a functor. 

Define the natural transformation 7 : lgee — T with components for each 
A € Set, na: A T(A) as na(a) = {a}. Note that for a morphism f : A— B 
in Set, we have, for any ac A 


(np © Iset(f))(@) = na ((Iset (f))(a)) 


I 


I 


l 


and 


so 7 is a natural transformation. 
Define the natural transformation py : ToT — T componentwise as the 
function 


wa(A) =|JA= {ae X| Xe A} 


In other words, let js map a set of sets into their union. We have 


(up oT(T(f)))(A) = wa (T(F(A)))) 

uB(T({ f(a) | a € A})) 

uB({X | X C {f(a) | @€ A}}) 
UX |X c{f@ | ae A} 
{f(a) | @€ A} 


l| 


and 


=T(F)(JA) 
={F(@) |ae|JA} 
={f(@) |e A} 


so yw is a natural transformation. 
Now that we have an endofunctor T, along with two natural transformations 


7, 4, we only need to show the monad laws are satisfied. 
As for the first law, denote A = {B;} with B; = {C;} and check 


(wo Tu)(A) = w(T(H)(A)) 
(Aj) | By € A}) 
4B; :C; € B; € A}) 
i, Bi: cE C, € B; € A} 








and 








satisfying the first monad law. 
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We have 








(0 T')(A) = w(T(n)(A)) 
= m({n(a) | a € A}) 
= u({{a} | a € Af) 
= {ax |dac A:ae€ {a}} 
=A 

and 

(wo nT’)(A) = w(n(T(A))) 
= w(n({X | XC A})) 
= w{{X | XC A}}) 
= {x | dX|x eX C A} 
=A 


We can now conclude that (T,7, 4) is a monad on Set. 


8.5 Connection to Haskell 


Since we have  : T? + T, we can view this transformation at an object a as 
join :: T (Ta) ->Ta 

which in Haskell is defined as 

join :: (Monad m) =>m (ma) ->ma 

join x = x >>= id. 

This means that a proper implementation of >>= gives us a proper implemen- 
taton of w. 


As for 7: le > T, we note that 1c(a) = a, so we get yn. : a > Ta, giving 
us the type of 
return :: a -> T a from the monad typeclass 

Note, however, that while both of the natural transformations are of the 
correct type, neither criterion is automatically satisfied. The programmer im- 
plementing return and >>= is responsible for making sure these criterion are 
satisfied. Not fulfilling these criterion will remove some of the mathematical 
consistency behind the monads, and possibly even render them useless. All 
monads that is implemented in Haskells standard library satisfy the criterion 
[4, Chapter 9]. 


8.5.1 Monad Laws in Haskell 


In order to effectively discuss the monad laws for Monad instances, we need 
to reformulate the laws to make sense in Haskell. The laws Haskell uses are 
equivalent to the laws of category theory, but this is not obvious since they are 
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simplified and separated into several smaller pieces. The monad laws of Haskell 
are [4, Chapter 13] 


(return a >>= k) =ka (1) 

(m >>= return) =m (2) 

x >>= (return . f) =fmap f x (3) 

(m >>= (\x -> k x >>= h)) = (m >>= k) >>=h (4) 


In order to show that these laws are equivalent, we assume that these laws hold 
for some monad, and show that it follows that the laws from category theory 
hold as well. 

We begin with the first law from category theory, WeT x = HelT(2), OF in 
Haskell terms 

join . (fmap join) = join . join . (fmap id) 

Since each Monad is also a functor, we can use the functor law fmap id = id 
to transform the above into join . fmap join = join . join. Transforming 
this using the Haskell laws, we get 


LHS = join . (fmap join) 
[def. (.)] = (\x -> join (fmap join x)) 
[(3)] = (\x -> join (x >>= (return . join))) 
[def. join} = (\x -> (x >>= (return . join)) >>= id) 
[((4)] = (\x -> x >>= (\y -> ((return . join) y) >>= id)) 
[def. (.)] = (\x -> x >>= (\y -> (return (join y)) >>= id)) 
[((1)] = (x -> x >>= (\y -> id (join y))) 
[def. id] = (\x -> x >>= (\y -> join y)) 
[def. join} = (\x -x >>= (\y —> y >>= id)) 
[def. id] = (\x -> x >>= (\y -> id y >>= id)) 
[(4)] = (\x -> (x >>= id) >>= id) 
[def. join} = (\x -> join (x >>= id)) 


[def. join} = (\x -> join (join x)) 





[def. (.)] = join . join 
= AS 


The second law, W27(2) = Hel Ne = id, translates into 


join . return = join . fmap return = id 


which we split into two equations 


join . return = id 


join . fmap return = id 
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Once again we transform using the haskell laws, starting with the first equation 


LHS, = join . return 


[def. (.)] = (\x -> join (return x)) 
[def. join} = (\x -> return x >>= id) 
[((1)] = (\x -> id x) 
[eta-conversion] = id= RHS; 


And for the second equation we get 


LHS, = join . fmap return 
[(3)] 
[eta-conversion] = (\x -> (x >>= (\y -> (return (return y)) >>= id))) 
[((1)} = (\x -> (x >>= (\y -> id (return y)))) 
[reverse eta-conversion] = (\x -> (x >>= return)) 
= (\x -> x) =id= RHS, 


= (\x -> (x >>= return . return) >>= id) 


Thus we have that given an instance of the Monad typeclass that satisfies the 
Haskell monadic laws, it is indeed a monad on Hask. To show equivalence be- 
tween the two sets of laws, one needs to show implication in the other direction. 
However, for the purposes of this paper, this is not needed. 


8.5.2 Maybe is a Monad 


We know that Maybe is a functor on Hask, so to show that it is a monad on 
Hask, we only need to show the monadic laws. 
Let the Maybe monad be defined as previously stated, and consider 


LHS, 

[def. return (p. 13)] = (pure a >>= k) 

[def. pure (p. 12)] = (Just a >>= k) 
[def. >>= (p. 13)]) = k x= RHS) 


(return a >>= k) 


I 


LHS) = (m >>= return) 


[def. return, pure] (m >>= Just) 


I 








ap _ Nothing >>= Just | m = Nothing 
epi inte Cares onan = { Just x >>= Just m= Just x 
Nothing = Nothing 
. >>=| = 
Ide { Just x m= Just x 
= n= RH S»2 
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RHS3; = fmap f x 
[Split into cases for x] = { 


[def. fmap (p. 9)] = { aioe: 


LHS3 = x >>= (return . f) 


fmap f Nothing 
fmap f (Just y) 


Just (f y) 





x = Nothing 
x = Just y 





[def. (.)] = x >>= (\a -> return (f a)) 
[def. return, pure] = x >>= (\a -> Just (f a)) 


Nothing >>= (\a 
Just y >>= (\a 


a Nothing 
ade oe { Just (f y) 


[Split into cases for x] = { 


x= 





x = 





Which gives us LH S3 = RHS3. 


-> Just (f a)) |x 
-> Just (f a)) |x 


Nothing 
Just y 


As for the fourth law, we have two cases, eitherm = Nothing orm 


For the first case, we get 


LHS, = Nothing >>= (\x -> k x >>= h) 


[def. >>=] = Nothing 


and 


RAS, = (Nothing >>= k) >>=h 


[def. >>=] = Nothing >>= 


[def. >>=] = Nothing 


h 


So LHS4 = RHS4. As for the second case, we have 


LHS, = Just x >>= (\x -> k x >>= h) 


[def. >>=| = k x >>=h 


and 


RHS4= (Just x >>= 


[def. >>=| = k x >>=h 


So, again, LHS, = RH S4, giving us that Maybe is indeed a monad. 
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k) >= h 


x = Nothing 
x = Just y 


Nothing 
Just y 


Just: x: 


8.5.3 List is a Monad 


Recall that we have already shown that the list functor in Haskell is indeed a 
functor on Hask. 
The Monad instance can be defined as 


instance Monad [] where 


xs >>= f = (concat' (fmap f xs)) 
return x = [x] 
concat' :: [[a]] -> [a] 
concat' [] = [] 
concat' ([] : xs) = concat' xs 
concat' ((x : xs) : ys) = x : concat' (xs : ys) 


where concat' takes a list of lists as argument, and concatenates its elements. 
First, we state that List is indeed an endofunctor, since it is a functor from 
Hask to Hask. It is also equipped with the natural transformations 7, W as 
return, join. 
We consider the Haskell equivalents of the monadic laws and state that 


LHS, =return x >>= f 
[def. return] = [x] >>= f 
[def. >>=]| = concat' [f x] 
=fx 
= RHS, 


and 


LHS2 =m >>= return 


[annotate the list m] = [m1,m2,...] >>= return 
[def. >>=] = concat' (fmap return [m1,m2,...]) 
(def. fmap (p. 9)] = concat' [[m1], [m2],[...]] 
[apply concat'] = [m1,m2,...] 
=m 
= RHS» 


meaning both unit laws hold. 
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Examining the third law gives us 


LHS; = (x >>= (return . f)) 
[def. >>=] = concat' (fmap (return . f) x) 
[annotate the list x concat' (fmap (return . f) [x1, x2, ...]) 


= 
(def. fmap] = concat' [[f x1], [f x2], ...] 
|= 


[apply concat' [f xi, f x2, ...] 
(def. fmap] = fmap f x 
= RHS3 


As for the associative law, note the following corollary 


f mi ++ f m2 ++... 


m >>= f= [mi1, m2, ...] >>=f 
[def. >>=] = concat'! (fmap f [m1, m2, ...]) 
[def. fmap] = concat' [f mi, f m2, ...] 


[def. concat' 


i.e. a list consisting of the concatenated results of applying f to the elements of 
m. Using this we get 


LHS, = (m >>= f) >>= g 
[corollary] = (f ml ++ f m2 ++ ...) >>= g 
[def. >>=] = concat' (fmap g (f mi ++ f m2 ++ ...)) 
[distribute fmap over ++] = concat'(fmap g (f mi) ++ fmap g (f m2) ++ ...) 


[distribute concat' over fmap] = concat' (fmap g (f m1)) ++ concat' (fmap g (f m2)) ++ ... 


RHS,= m >>= (\x -> £ x >>= g) 
[corollary] = f m1 >>= g ++ f m2 >>= g t+... 
[def. >>=] = concat' (fmap g (f m1)) ++ concat' (fmap g (f m2)) ++... 


So LHS, = RHS4, and the associative law is satisfied. With this we can 
conclude that the list monad in Haskell is indeed a monad on Hask. 


9 Conclusion 
After exploring these concepts, we can see that there is a lot of room for math- 
ematical abstractions in the field of computer science. Understanding these 


abstractions will make working in functional languages easier, and will provide 
more legible code — given that your reader also understands these concepts. 
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Due to the simple syntax of do-notation in Haskell, the monad also provides 
a point of entry for those who are not well versed in functional programming. 
By using this simplified syntax, and thinking of it imperatively, you can write 
code first, learn the simpler concepts of currying, higher order functions and 
so on, and later develop an understanding of the underlying structure of the 
functor, the applicative and the monad, should you choose to do so. 


10 Related Work 


The approach to understanding Haskell and category theory in parallel is tried 
and tested by many authors. The Haskell wiki - as an example - uses the same 
approach, but with a larger focus on Haskell. The category theory explained is 
contained in much the same form of presentation in the referenced books; which 
focus less - if at all - on Haskell. 


11 Future Work 


There is much to learn about both category theory and the Haskell abstrac- 
tions. The next step in category theory is to be more thorough, following a 
strictly mathematical and rigorous textbook. The textbooks [1] and [3] are 
good examples. 

Further reading on Haskell abstractions is available in multiple textbooks, 
and the next concept is likely that of lenses, that allow for easy modification of 
components of composite data types[5] 


12 Analysis 


As previously mentioned, exploring category theory and Haskell in parallell is 
not anew concept. However, finding a middle ground — with practical examples 
along with abstract theories — the goal was to make accessible introductions 
for those who are equally versed in mathematics and computer science. This 
goal has been adequatly fulfilled, by explaining the needed theory compactly 
and without unneccessary details. 
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A Monads as Monoids 


A.1 Product Categories 


Let C, D be categories. The product category C x D consists of the objects (a, b), 
where a € C,b € D, and morphisms (f,g) where f is a morphism on C, and g 
is a morphism on D. 

The composition on Cx D is the composition of the components, i.e. (f,g)o 
(a, 8) = (foa, go). The identity morphisms are the pair of identitiy morphisms 
of objects in C, D, ie. (1c, 14), for ce Cid € D. 


A.2 Monoidal Category 
A Monoidal category [1, p.161] is a category C along with 


1. A bifunctor — a functor whose domain is a product category — called 
tensor product ® : Cx C' + C, where x is the cartesian product from set 
theory. 


2. An object i € C called the unit object. 


3. Three natural isomorphisms, that together demand that the tensor oper- 
ation satisfies 


(a) Associativity, through the isomorphism dape :: (a®b)@c > a®(b@c), 
often called the associator 
(b) Identity, shown by two isomorphisms; 
i. The Left unitor \y:1@a>a 
ii. The Right unitor pg: a®Qi-ra. 


Qaib 





(a@t)xb a® (i x b) 
a@®b 


A.3  Monoid in a monoidal category 


Let C be a monoidal category with tensor product ®. In order to create a 
monoid in C’, we start by picking an object m € C’. Pick two morphisms on C: 
Urmem>m 

nit—am 

where 2 is the unit object of ®. Note that the source for the morphism yp is the 
result of applying the tensor product m ® m, which is an object in C. Further, 


34 


these morphisms must satisfy associativity 


(m ®m) ®m ——*—> m @ (m@m) 


| ou |ison 


mem mem 
m 


: n®id id®n i 
1@m —>mOSm<=-aA— MBit 


See 


m 


and unit laws 


Remember the definition for a monoid, that requires a set of objects M, anda 
way to combine said objects, -. If we take a monoidal category C, with tensor 
product ®, we can let 7 € C, the unit object of ®, be the identity object in a 
monoid M. The tensor product can then act as the combination operator -, and 
the monoid behaves as expected, due to the laws set on ® [1, p.170]. 


A.4 Monoid in the Category of Endofunctors 


Next, we look at the category of endofunctors on C’, the category commonly 
denoted [C,C]. A monoid in this category requires a tensor product — to 
turn the category into a monoidal category. The tensor product is of the form 
® : [C,C] x [C,C] > [C,C], meaning it takes two endofunctors and combines 
them into one. The most intuitive way to do said combining is by endofunctor 
composition. 

Take two functors F,G € [C,C]. Their composition, Fo G, is also an 
endofunctor on C, so intuitively, we could use endofunctor composition as a 
tensor product. However, in order to do so, we must formally prove that it 
satisfies the conditions. 

First, we need to show that it is a bifunctor. The type signature of endo- 
morphism composition is o : [C,C] x [C,C] > [C,C], which shows that if it is 
a functor, it is also a bifunctor. The first condition for functors requires that 
FoG(1x) = lroax) for all X in C. Since both F and G are functors, it follows 
that 


FoG(1x) = F(G(1x)) = F(ecx)) = levecx)) = lroa(x) 


Next, morphism composition must be preserved, and we have 


FoG(fg) = F(G(f9)) = F(GP)(G))) = FUGA) F(GY)) = FoG(f) FoG(g) 
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meaning that o is indeed a bifunctor on [C, C]. 

We can use the identity functor le as the unit object on [C, C], which means 
that we need no natrual isomorphisms A, p to force identity, since 1c already 
satisfies it. As for associativity, we have 


Fo(GoH)=(FoG)oH 


Meaning we have no need for the associator. 

We can thus conclude that the category of endofunctors on a category is a 
monoidal category with functor composition as tensor product. What needs to 
be stated now is what a monoid in this category is. 

We need to pick an object T € C with morphisms uw: T@T > T,n:1-> T. 
In the category of endofunctors this translates to selecting an endofunctor and 
two natural transformations. 

Since our tensor product is endofunctor composition, and our identity is lc, 
the identity functor of C, we get : ToT > T and 7: le — m Note that these 
type signatures correspond exactly to those of the monad. 

The conditions set upon a monoid in a monoidal category require associa- 
tivity, which when applying our endofunctor notation transforms into 


T3 TH pe 


a 


(nr & 
Lb 


Note the lack of the @ arrow. Since endofunctor composition is associative, 
we can simply state that To (ToT) = (ToT)oT. Also note that this law 
corresponds exactly to the first law set upon a monad [1, p. 137]. 

Note that T= 1l¢coT=To lg, so we have for the unit law diagram 


(eer a ope — pie 2s a 


Nee ANI 


T? 


Which corresponds exactly to the second law of the monad. From this we 
can conclude that — as previously suggested — the monad is a monoid in the 
category of endofunctors. 
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